The Emergency Broadcast System (“EBS”) was a well known emergency warning system in the United States, used from 1963 to 1997, but which was replaced by the Emergency Alert System (“EAS”) in 1994. Jointly coordinated by the Federal Communications Commission (FCC), Federal Emergency Management Agency (FEMA), and the National Weather Service (NWS), the EAS is designed to enable the President of the United States to speak to the United States within 10 minutes, and to allow local geographical zones to be addressed by local authorities, when needed. Hence, each State has its own EAS plan to allow it to take advantage of the national EAS system. The EAS regulations and standards are governed by the Public Safety and Homeland Security Bureau of the FCC.
The EAS expanded the communication coverage previously offered by the EBS and now uses a plethora of communications mediums to communicate messages. For example, the EAS now covers general radio type signals such as AM/FM/ACSSB(R)(LM(R)), general broadcast television signals such as VHF Low/VHF Medium/VHF High/UHF stations, cable television including systems that support HRC/IRC/ICC/STD/EIA, wireless cable television, Digital television, digital cable, XM Satellite Radio, Sirius Satellite Radio, Worldspace, In-band on-channel (IBOC) communications, Digital Audio Broadcasting (DAB), DIRECTV, the Dish Network, Muzak, DMX Music, Music Choice, all other Direct Broadcast Satellite providers, and Video Dial Tone (OVS) services.
The FCC requires all broadcast stations (see above list of types) to install and maintain EAS decoders and encoders at their control points. These decoders continuously monitor the signals from other nearby broadcast stations for EAS messages. For reliability, at least two other source stations must be monitored, one of which must be a designated local primary. Broadcast stations are also required to be aware of the latest EAS protocols, maintain the latest version of the EAS handbook, and keep logs of all received and transmitted EAS messages, which are typically recorded electronically on a personal computer.
In addition to the audio messages transmitted by radio stations, television stations must also transmit a visual message such as text “crawl” displayed at the top of a transmitted display screen. A color coded “crawl” system is often used where the color signifies the priority of the message, but some television stations transmit only a visual message. A television station may be used for monitoring by another station and, thus, an audio signal also is necessary.
Upon reception of an alert, a station must relay an Emergency Action Notification (“EAN”) and an Emergency Action Termination (“EAT”) message immediately to their listeners/viewers and other stations. Some stations have been allowed to “opt out” of relaying some alerts, such as severe weather and child abduction emergencies (e.g. AMBER Alerts), and some stations may be “non-participating” type stations and do not relay any messages. Instead they transmit a message instructing listeners/viewers to tune to another station for the broadcasted information, and they must then suspend their own operation.
A digital version of EAS called Digital Emergency Alert System (DEAS) is currently being rolled out to the US after the implementation of a pilot program and is designed to deliver next generation alert and warning capabilities to the American public. DEAS is a wireless digital data delivery system that utilizes a process called “datacasting” which is a one-way broadcast service. The intent of the new DEAS system is to utilize existing high-speed networks to stream video or disseminate large files to thousands of locations simultaneously through a process called “datacasting.”
Datacasting offers the potential to reach greater distribution audience and provide greater amounts of information to a warning recipient. In theory, the technology will allow the DEAS system to be addressable so that public safety officials can pinpoint to whom the information is sent, and distribute critical information over a variety of media, such as cell phones, PDAs, pagers and computers. Datacasts are transmitted through a digital television signal and a receiver hooked up to a personal computer, laptop or computer network. However, homes, schools, government buildings and businesses can only receive the alerts and information in a datacast by installing a special receiver and antenna. Hence, while high-speed networks are utilized to transfer digital files, the existing radio broadcasting systems are utilized to reach listing public and the existing Internet WWW services are not utilized. Since, special equipment is required for a personal computer to become a recipient of any broadcast alerts, incorporation of even a modest percentage of personal computers in use in the U.S. is unlikely.
It is surprising that the Internet is not fully included in the EAS, or the DEAS, notwithstanding the fact that the Internet has become a ubiquitous data communications channel for a majority of the US population. However, the reason is likely that the implementation of the current EAS or DEAS systems on the Internet is not feasible as the topology of the Internet is a distributed network, and no centralized authority currently controls access to services offered over the Internet, as was purposeful in is design. Nevertheless, a type of centralized control may be implemented voluntarily throughout the world wide web through manipulation of the current domain naming conventions of the Internet, as will be disclosed. Hence, some understanding of the structure and function of certain aspects of the Internet are required in order to appreciate the herein disclosed centralized system.
The “Domain Name System” on the Internet associates various sorts of information with so-called “domain names” and provides for a user friendly addressing process for the Internet by translating human-readable computer host names into the IP addresses. This process is known as “name resolution” and may be handled in various ways, but the most common method is for name translations to occur through the DNS system (hereinafter “Internet DNS” or simply “DNS”). For example, the numerical address 66.230.200.100 is provided to Internet users' machines when the human readable address www.wikipedia.org is typed into an Internet browser addressing bar. The translation of a domain name or other human readable text into IP addresses provides the addressing scheme that networking equipment needs to deliver webpages to PCs around the world, and to provide other information such as addresses for mail exchange servers and other services available over the Internet. In providing a worldwide keyword-based addressing scheme (i.e. essentially a redirection service), DNS is a critical component for the functioning of today's Internet. Since the Internet is the dominant medium through which most information is propagated throughout the world, the implementation of DNS is nothing less than a monumental data communications achievement.
While other computer programs exist that process name resolution requests from computer to computer on a network, as of the filing of this application the most prevalent method for Internet name resolution is dictated by the aforementioned DNS process invented by Paul Mockapetris in 1983 and governed by RFC (“Request for Comment”) 1034 and 1035 as adopted by the Internet Engineering Task Force (IETF) in 1986. RFCs 1034 and 1035 made obsolete the prior RFCs 882, 883, 973 as adopted circa 1983-84. DNS is one of the original Internet standards, although new applications and extensions to DNS are continually being evaluated by IETF and the Internet community at large. The RFCs 1034 and 1035 specification is hereby incorporated by reference.
While the total scope and operation of DNS is not necessary for a complete understanding of the herein described centralized deflection system, a few concepts are described below to facilitate the implementation of the centralized system, as discussed in the description of the preferred embodiments.
Name resolution in its simplest form is achieved by an ASCII text conversion table stored on each computer, traditionally know as a “HOSTS” file. At a local network level, a lookup table is maintained to list different machines that are added to the network and assigned numbers associated with each machine name through a program such as Windows DHCP program. The lookup table on a local network is updated only once for each new machine that is added (e.g. a new PC, a router, a printer, etc.) and is usually administered by a local DNS type program, such as the Microsoft Windows based program “WINS” (Windows Internet Name Service). Since HOST files are updated manually, and since even an automatically updated conversion file saved on a local machine would become impossibly large to accommodate all of the domain names used on the Internet, DNS changes this to delegate the lookup or resolution process across a distributed plane of name servers.
When an entity registers a human readable domain name (currently, letters and numbers and a few special symbols, but this is being expanded) with one of the dozens of ICANN authorized registrars (e.g. www.register.com), the registering entity specifies two DNS servers associated with a selected domain name, a primary and a backup DNS server. These servers are the authoritative sources for DNS information regarding the selected domain name and machines connected to a network on the domain. When a user of the Internet attempts to contact a system in the network domain of the registered domain name, the machine utilized by the user will check progressively from its own DNS server's lookup table, to other machines connected thereto, to Internet core servers, and finally to the authoritative servers themselves to translate the spelled name into an IP address. This occurs through the action of a program in the DNS system called a “recursor” that sends and responds to addressing queries from other DNS servers in an iterative process. Currently, a popular UNIX based DNS resolution program that includes a recursor is BIND (“Berkeley Internet Name Domain”). Responses from these recursor programs usually are either error messages or a “pointer” to which the recursor program might send additional queries to find the host machine. Upon receiving a request, a DNS server contacted by a recursor program of another DNS server can respond in four ways:                1. It can answer the request with an IP address because it already knows the IP address for the domain.        2. It can contact another name server and try to find the IP address for the name requested. It may have to do this multiple times.        3. It can say, “I don't know the IP address for the domain you requested, but here's the IP address for a name server that knows more than I do.”        4. It can return an error message because the requested domain name is invalid or does not exist.This process is iteratively continued until a name is resolved and the host computer is contacted.        
Once the resolution process is complete, in theory, various DNS server machines, and other intermediate name resolution machines, will propagate the human readable name's IP address association to their tables so that name resolution is facilitated across the Internet. Further, local DNS tables are configured to retain information (referred to as “caching”) so that addresses used most often by its domain users are quickly accessible to facilitate the rapid functioning of DNS.
Usually, an ISP like “yahoo” or “Earthlink” will administer domain names and their associated webpages and resources for a contracting an entity. But, quite often, organizations will maintain their own domain name and resources. For example, “HowStuffWorks” a well known information Internet site maintains their own machines dedicated to their website, including administering their own DNS server. As published on their website, they have a primary server and a secondary, as such:
AUTH-NS1.HOWSTUFFWORKS.COM 209.116.69.78
AUTH-NS2.HOWSTUFFWORKS.COM 209.116.69.79
Their primary DNS is auth-ns1.howstuffworks.com and any changes they make to this site is automatically propagated to the listed secondary site, which is maintained not by them, but by their ISP.
HOWSTUFFWORKS uses the name server software BIND for their domain and they have a zone file (similar to the functioning of a HOST file, but formatted for DNS) on their host DNS server having the following form:
@NSauth-ns1.howstuffworks.com.@NSauth-ns2.howstuffworks.com.@MX 10mailmailA209.170.137.42server1A216.183.103.150wwwCNAMEserver 1
This is a typical zone file and has the following meaning. The first two lines point to the primary and secondary name servers. The next line is called the “MX record” which indicates that it is a Mail Exchange or e-mail SMTP server with the name “mail.” The next line indicates the IP address for the machine that handles a request to mail.howstuffworks.com, which handles the mail. The next line indicates to the main machine (server1) that will handle requests to howstuffworks.com. This line is also know as the “A NAME” record which lists the primary computer IP address. The next, and last, line points to the IP address that will handle requests to www.howstuffworks.com.
As seen in the information in the zone file, several physical computer machines at separate IP addresses make up the computer server infrastructure for the website www.howstuffworks.com. And, one will also note that a “CNAME” record appears in the above zone file on the last line. CNAME is short for “canonical name,” which is usually referred to as a CNAME record. A CNAME record in a DNS database, like the zone file above, is a record that indicates the true, or “canonical,” host name of a computer with which its aliases are associated.
CNAME records can be used when a computer or service needs to be renamed to temporarily allow access through both the old and new name, or to point a sub-domain to another domain, or to have a sub-domain point to a computer outside of the host domain. In the above zone file example, the CNAME record redirects all world web entries http://www.howstuffworks.com to the “server1” IP address listed under the A Name record. CNAMES are often used to redirect address bar mistakes entered into Internet browser software fields. For example, many HOST record files redirect incorrect entries like http://wwww.domainname.com and http://ww.domainname.com to http://www.domainname.com, which is helpful for instances when an Internet user do not enter the correct number of “w”s in the browser address bar of their Internet browser program like Internet Explorer. The complete usage and acceptable forms of CNAMEs may be found in RFC 1034.
As was fully discussed in application Ser. No. 11/961,686, the usage of CNAMEs provides a means for redirecting access to websites, domains, sub-domains, resource records, etc., and it may be done in an automated fashion. Pursuant to the referenced application, the automated altering of zone files permits the “deflection” of websites when combined with novel uses of CNAMEs. Further, the alteration of a websites function and appearance is also possible using CNAME manipulation in zone files.
Nevertheless, the redirection of webpages to provide an alternative content to be delivered to a requestor over the Internet, such as if the computer server delivering the original content is destroyed in a disaster event, does not provide a means for a central authority to broadcast an emergency message to a computer user accessing various websites on the Internet.
Hence, what is needed is a centralized system for quickly and simply providing emergency messages to websites either subscribing to or being required to implement an emergency broadcast system. The system should either be integrated with the EAS or DEAS, or be available as an adjunct to these systems. The implementation of this process should cause no disruption to the Internet structure, including especially DNS, so that access to the websites will not be otherwise inhibited.